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Foreword 


The  Federal  Information  Processing  Standards  Publication  Series  of  the  National  Institute 
of  Standards  and  Technology  (NIST)  is  the  official  series  of  publications  relating  to 
standards  and  guidelines  adopted  and  promulgated  under  the  provisions  of  Section  5131 
of  the  Information  Technology  Management  Reform  Act  of  1996  (Public  Law  104-106) 
and  the  Computer  Security  Act  of  1987  (Public  Law  100-235).  These  mandates  have 
given  the  Secretary  of  Commerce  and  NIST  important  responsibilities  for  improving  the 
utilization  and  management  of  computer  and  related  telecommunications  systems  in  the 
Federal  government.  The  NIST,  through  its  Information  Technology  Laboratory, 
provides  leadership,  technical  guidance,  and  coordination  of  government  efforts  in  the 
development  of  standards  and  guidelines  in  these  areas. 

Comments  concerning  Federal  Information  Processing  Standards  Publications  are 
welcomed  and  should  be  addressed  to  the  Director,  Information  Technology  Laboratory, 
National  Institute  of  Standards  and  Technology,  100  Bureau  Drive,  Stop  8900, 
Gaithersburg,  MD  20899-8900. 


William  Mehuron,  Director 
Information  Technology 
Laboratory 


Abstract 

This  standard  describes  a  keyed-hash  message  authentication  code  (HMAC),  a 
mechanism  for  message  authentication  using  cryptographic  hash  functions.  HMAC  can 
be  used  with  any  iterative  Approved  cryptographic  hash  function,  in  combination  with  a 
shared  secret  key.  The  cryptographic  strength  of  HMAC  depends  on  the  properties  of  the 
underlying  hash  function.  The  HMAC  specification  in  this  standard  is  a  generalization  of 
Internet  RFC  2104,  HMAC ,  Keyed-Hashing  for  Message  Authentication ,  and  ANSI 
X9.71,  Keyed  Hash  Message  Authentication  Code. 

Keywords :  computer  security,  cryptography,  HMAC,  MAC,  message  authentication, 
Federal  Information  Processing  Standard  (FIPS). 
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Announcing  the  Standard  for 

The  Keyed-Hash  Message  Authentication  Code  (HMAC) 


Federal  Information  Processing  Standards  Publications  (FIPS  PUBS)  are  issued  by  the 
National  Institute  of  Standards  and  Technology  (NIST)  after  approval  by  the  Secretary  of 
Commerce  pursuant  to  Section  5131  of  the  Information  Technology  Management  Reform 
Act  of  1996  (Public  Law  104-106)  and  the  Computer  Security  Act  of  1987  (Public  Law 
100-235). 

1.  Name  of  Standard.  Keyed-Hash  Message  Authentication  Code  (HMAC)  (FIPS 
PUB  198). 

2.  Category  of  Standard.  Computer  Security  Standard.  Subcategory.  Cryptography. 

3.  Explanation.  This  standard  specifies  an  algorithm  for  applications  requiring  message 
authentication.  Message  authentication  is  achieved  via  the  construction  of  a  message 
authentication  code  (MAC).  MACs  based  on  cryptographic  hash  functions  are  known  as 
HMACs. 

The  purpose  of  a  MAC  is  to  authenticate  both  the  source  of  a  message  and  its  integrity 
without  the  use  of  any  additional  mechanisms.  HMACs  have  two  functionally  distinct 
parameters,  a  message  input  and  a  secret  key  known  only  to  the  message  originator  and 
intended  receiver(s).  Additional  applications  of  keyed-hash  functions  include  their  use  in 
challenge-response  identification  protocols  for  computing  responses,  which  are  a  function 
of  both  a  secret  key  and  a  challenge  message. 

An  HMAC  function  is  used  by  the  message  sender  to  produce  a  value  (the  MAC)  that  is 
formed  by  condensing  the  secret  key  and  the  message  input.  The  MAC  is  typically  sent  to 
the  message  receiver  along  with  the  message.  The  receiver  computes  the  MAC  on  the 
received  message  using  the  same  key  and  HMAC  function  as  was  used  by  the  sender,  and 
compares  the  result  computed  with  the  received  MAC.  If  the  two  values  match,  the 
message  has  been  correctly  received,  and  the  receiver  is  assured  that  the  sender  is  a 
member  of  the  community  of  users  that  share  the  key. 

The  HMAC  specification  in  this  standard  is  a  generalization  of  HMAC  as  specified  in 
Internet  RFC  2104,  HMAC,  Keyed-Hashing  for  Message  Authentication ,  and  ANSI 
X9.71,  Keyed  Hash  Message  Authentication  Code. 

4.  Approving  Authority.  Secretary  of  Commerce. 
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5.  Maintenance  Agency.  Department  of  Commerce,  National  Institute  of  Standards 
and  Technology,  Information  Technology  Laboratory  (ITL). 

6.  Applicability.  This  standard  is  applicable  to  all  Federal  departments  and  agencies  for 
the  protection  of  sensitive  unclassified  information  that  is  not  subject  to  section  2315  of 
Title  10,  United  States  Code,  or  section  3502(2)  of  Title  44,  United  States  Code.  This 
standard  shall  be  used  in  designing,  acquiring  and  implementing  keyed-hash  message 
authentication  techniques  in  systems  that  Federal  departments  and  agencies  operate  or 
which  are  operated  for  them  under  contract.  The  adoption  and  use  of  this  standard  is 
available  on  a  voluntary  basis  to  private  and  commercial  organizations. 

7.  Specifications.  Federal  Information  Processing  Standard  (FIPS)  198,  Keyed-Hash 
Message  Authentication  Code  (HMAC)  (affixed). 

8.  Implementations.  The  authentication  mechanism  described  in  this  standard  may  be 
implemented  in  software,  firmware,  hardware,  or  any  combination  thereof.  NIST  has 
developed  a  Cryptographic  Module  Validation  Program  that  will  test  implementations  for 
conformance  with  this  HMAC  standard.  Information  on  this  program  is  available  at 
http://csrc.nist.gov/cryptval/. 

Agencies  are  advised  that  keys  used  for  HMAC  applications  should  not  be  used  for  other 
purposes. 

9.  Other  Approved  Security  Functions.  HMAC  implementations  that  comply  with  this 
standard  shall  employ  cryptographic  algorithms,  cryptographic  key  generation  algorithms 
and  key  management  techniques  that  have  been  approved  for  protecting  Federal 
government  sensitive  information.  Approved  cryptographic  algorithms  and  techniques 
include  those  that  are  either: 

a.  specified  in  a  Federal  Information  Processing  Standard  (FIPS), 

b.  adopted  in  a  FIPS  or  NIST  Recommendation  and  specified  either  in  an  appendix  to 
the  FIPS  or  NIST  Recommendation  or  in  a  document  referenced  by  the  FIPS  or 
NIST  Recommendation,  or 

c.  specified  in  the  list  of  Approved  security  functions  for  FIPS  140-2. 

10.  Export  Control.  Certain  cryptographic  devices  and  technical  data  regarding  them 
are  subject  to  Federal  export  controls.  Exports  of  cryptographic  modules  implementing 
this  standard  and  technical  data  regarding  them  must  comply  with  these  Federal 
regulations  and  be  licensed  by  the  Bureau  of  Export  Administration  of  the  U.S. 
Department  of  Commerce.  Applicable  Federal  government  export  controls  are  specified 
in  Title  15,  Code  of  Federal  Regulations  (CFR)  Part  740.17;  Title  15,  CFR  Part  742;  and 
Title  15,  CFR  Part  774,  Category  5,  Part  2. 

11.  Implementation  Schedule.  This  standard  becomes  effective  on  September  6,  2002. 
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12.  Qualifications.  The  security  afforded  by  the  HMAC  function  is  dependent  on 
maintaining  the  secrecy  of  the  key.  Therefore,  users  must  guard  against  disclosure  of 
these  keys.  While  it  is  the  intent  of  this  standard  to  specify  a  mechanism  to  provide 
message  authentication,  conformance  to  this  standard  does  not  assure  that  a  particular 
implementation  is  secure.  It  is  the  responsibility  of  the  implementer  to  ensure  that  any 
module  containing  an  HMAC  implementation  is  designed  and  built  in  a  secure  manner. 

Similarly,  the  use  of  a  product  containing  an  implementation  that  conforms  to  this 
standard  does  not  guarantee  the  security  of  the  overall  system  in  which  the  product  is 
used.  The  responsible  authority  in  each  agency  shall  assure  that  an  overall  system 
provides  an  acceptable  level  of  security. 

Since  a  standard  of  this  nature  must  be  flexible  enough  to  adapt  to  advancements  and 
innovations  in  science  and  technology,  this  standard  will  be  reviewed  every  five  years  in 
order  to  assess  its  adequacy. 

13.  Waiver  Procedure.  Under  certain  exceptional  circumstances,  the  heads  of  Federal 
agencies,  or  their  delegates,  may  approve  waivers  to  Federal  Information  Processing 
Standards  (FIPS).  The  heads  of  such  agencies  may  redelegate  such  authority  only  to  a 
senior  official  designated  pursuant  to  Section  3506(b)  of  Title  44,  U.S.  Code.  Waivers 
shall  be  granted  only  when  compliance  with  this  standard  would 

a.  adversely  affect  the  accomplishment  of  the  mission  of  an  operator  of  Federal 
computer  system  or 

b.  cause  a  major  adverse  financial  impact  on  the  operator  that  is  not  offset  by 
government-wide  savings. 

Agency  heads  may  act  upon  a  written  waiver  request  containing  the  information  detailed 
above.  Agency  heads  may  also  act  without  a  written  waiver  request  when  they  determine 
that  conditions  for  meeting  the  standard  cannot  be  met.  Agency  heads  may  approve 
waivers  only  by  a  written  decision  that  explains  the  basis  on  which  the  agency  head  made 
the  required  finding(s).  A  copy  of  each  such  decision,  with  procurement  sensitive  or 
classified  portions  clearly  identified,  shall  be  sent  to:  National  Institute  of  Standards  and 
Technology;  ATTN:  FIPS  Waiver  Decision,  Information  Technology  Laboratory,  100 
Bureau  Drive,  Stop  8900,  Gaithersburg,  MD  20899-8900. 

In  addition,  notice  of  each  waiver  granted  and  each  delegation  of  authority  to  approve 
waivers  shall  be  sent  promptly  to  the  Committee  on  Government  Operations  of  the  House 
of  Representatives  and  the  Committee  on  Government  Affairs  of  the  Senate  and  shall  be 
published  promptly  in  the  Federal  Register. 

When  the  determination  on  a  waiver  applies  to  the  procurement  of  equipment  and/or 
services,  a  notice  of  the  waiver  determination  must  be  published  in  the  Commerce 
Business  Daily  as  a  part  of  the  notice  of  solicitation  for  offers  of  an  acquisition  or,  if  the 
waiver  determination  is  made  after  that  notice  is  published,  by  amendment  to  such  notice. 
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A  copy  of  the  waiver,  any  supporting  documents,  the  document  approving  the  waiver  and 
any  supporting  and  accompanying  documents,  with  such  deletions  as  the  agency  is 
authorized  and  decides  to  make  under  Section  552(b)  of  Title  5,  U.S.  Code,  shall  be  part 
of  the  procurement  documentation  and  retained  by  the  agency. 

14.  Where  to  obtain  copies.  This  publication  is  available  by  accessing 
http://csrc.nist.gov/publications/.  A  list  of  other  available  computer  security  publications, 
including  ordering  information,  can  be  obtained  from  NIST  Publications  List  91,  which  is 
available  at  the  same  web  site.  Alternatively,  copies  of  NIST  computer  security 
publications  are  available  from:  National  Technical  Information  Service  (NTIS),  5285 
Port  Royal  Road,  Springfield,  V A  22161. 
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1. 


INTRODUCTION 


Providing  a  way  to  check  the  integrity  of  information  transmitted  over  or  stored  in  an 
unreliable  medium  is  a  prime  necessity  in  the  world  of  open  computing  and 
communications.  Mechanisms  that  provide  such  integrity  checks  based  on  a  secret  key 
are  usually  called  message  authentication  codes  (MACs).  Typically,  message 
authentication  codes  are  used  between  two  parties  that  share  a  secret  key  in  order  to 
authenticate  information  transmitted  between  these  parties.  This  standard  defines  a  MAC 
that  uses  a  cryptographic  hash  function  in  conjunction  with  a  secret  key.  This  mechanism 
is  called  HMAC  and  is  a  generalization  of  HMAC  as  specified  in  [1]  and  [3]. 

HMAC  shall  be  used  in  combination  with  an  Approved  cryptographic  hash  function. 
HMAC  uses  a  secret  key  for  the  calculation  and  verification  of  the  MACs.  The  main 
goals  behind  the  HMAC  construction  [3]  are: 

•  To  use  available  hash  functions  without  modifications;  in  particular,  hash 
functions  that  perform  well  in  software,  and  for  which  code  is  freely  and  widely 
available, 

•  To  preserve  the  original  performance  of  the  hash  function  without  incurring  a 
significant  degradation, 

•  To  use  and  handle  keys  in  a  simple  way, 

•  To  have  a  well-understood  cryptographic  analysis  of  the  strength  of  the 
authentication  mechanism  based  on  reasonable  assumptions  on  the  underlying 
hash  function,  and 

•  To  allow  for  easy  replaceability  of  the  underlying  hash  function  in  the  event  that 
faster  or  more  secure  hash  functions  are  later  available. 

2.  GLOSSARY  OF  TERMS  AND  ACRONYMS 

2.1  Glossary  of  Terms 

The  following  definitions  are  used  throughout  this  standard: 

Approved :  FIPS-approved  or  NIST  recommended.  An  algorithm  or  technique  that  is 
either  1)  specified  in  a  FIPS  or  NIST  Recommendation,  or  2)  adopted  in  a  FIPS  or  NIST 
Recommendation  and  specified  either  the  FIPS  or  NIST  Recommendation,  or  in  a 
document  referenced  by  the  FIPS  or  NIST  Recommendation. 
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Cryptographic  key  (key):  a  parameter  used  in  conjunction  with  a  cryptographic  algorithm 
that  determines  the  specific  operation  of  that  algorithm.  In  this  standard,  the 
cryptographic  key  is  used  by  the  HMAC  algorithm  to  produce  a  MAC  on  the  data. 

Hash  function:  an  Approved  mathematical  function  that  maps  a  string  of  arbitrary  length 
(up  to  a  pre-determined  maximum  size)  to  a  fixed  length  string.  It  may  be  used  to 
produce  a  checksum,  called  a  hash  value  or  message  digest,  for  a  potentially  long  string 
or  message. 

Keyed-hash  based  message  authentication  code  (HMAC):  a  message  authentication  code 
that  uses  a  cryptographic  key  in  conjunction  with  a  hash  function. 

Message  Authentication  Code  (MAC):  a  cryptographic  checksum  that  results  from 
passing  data  through  a  message  authentication  algorithm.  In  this  standard,  the  message 
authentication  algorithm  is  called  HMAC,  while  the  result  of  applying  HMAC  is  called 
the  MAC. 


Secret  key:  a  cryptographic  key  that  is  uniquely  associated  with  one  or  more  entities.  The 
use  of  the  term  "secret"  in  this  context  does  not  imply  a  classification  level;  rather  the 
term  implies  the  need  to  protect  the  key  from  disclosure  or  substitution. 

2.2  Acronyms 

The  following  acronyms  and  abbreviations  are  used  throughout  this  standard: 

FIPS  Federal  Information  Processing  Standard 

FIPS  PUB  FIPS  Publication 

HMAC  Keyed-Hash  Message  Authentication  Code 

MAC  Message  Authentication  Code 

NIST  National  Institute  of  Standards  and  Technology 


2.3  HMAC  Parameters  and  Symbols 

HMAC  uses  the  following  parameters: 

B  Block  size  (in  bytes)  of  the  input  to  the  Approved  hash  function. 

H  An  Approved  hash  function. 

ipad  Inner  pad;  the  byte  x’36’  repeated  B  times. 

K  Secret  key  shared  between  the  originator  and  the  intended  receiver(s). 
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Ko  The  key  K  after  any  necessary  pre-processing  to  form  a  B  byte  key. 

L  Block  size  (in  bytes)  of  the  output  of  the  Approved  hash  function. 
opad  Outer  pad;  the  byte  x’5c’  repeated  B  times. 
t  The  number  of  bytes  of  MAC. 

text  The  data  on  which  the  HMAC  is  calculated;  text  does  not  include  the  padded  key. 

D 

The  length  of  text  is  n  bits,  where  0  <  n  <  2  -  8 B. 

x’AT  Hexadecimal  notation,  where  each  symbol  in  the  string  ‘AT  represents  4  binary 
bits. 

II  Concatenation 

©  Exclusive-Or  operation. 

3.  CRYPTOGRAPHIC  KEYS 

The  size  of  the  key,  K,  shall  be  equal  to  or  greater  than  LI 2,  where  L  is  the  size  of  the 
hash  function  output.  Note  that  keys  greater  than  L  bytes  do  not  significantly  increase  the 
function  strength.  Applications  that  use  keys  longer  than  /Tbytes  shall  first  hash  the  key 

using  H  and  then  use  the  resultant  L-byte  string  as  the  HMAC  key,  K.  Keys  shall  be 

chosen  at  random  using  an  Approved  key  generation  method  and  shall  be  changed 
periodically.  Note  that  the  keys  should  be  protected  in  a  manner  that  is  consistent  with  the 
value  of  the  data  that  is  to  be  protected  (i.e.,  the  text  that  is  authenticated  using  the 
HMAC  function). 


4.  TRUNCATED  OUTPUT 


A  well-known  practice  with  MACs  is  to  truncate  their  output  (i.e.,  the  length  of  the  MAC 
used  is  less  than  the  length  of  the  output  of  the  MAC  function  L).  Applications  of  this 
standard  may  truncate  the  output  of  HMAC.  When  a  truncated  HMAC  is  used,  the  t 
leftmost  bytes  of  the  HMAC  computation  shall  be  used  as  the  MAC.  The  output  length,  t. 


shall  be  no  less  than  four  bytes  (i.e.,  4  <  t  <  L).  However,  t  shall  be  at  least  —bytes  (i.e., 


t  <  L)  unless  an  application  or  protocol  makes  numerous  trials  impractical.  For 

example,  a  low  bandwidth  channel  might  prevent  numerous  trials  on  a  4  byte  MAC,  or  a 
protocol  might  allow  only  a  small  number  of  invalid  MAC  attempts.  See  Appendix  B. 
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5. 


HMAC  SPECIFICATION 


To  compute  a  MAC  over  the  data  'text'  using  the  HMAC  function,  the  following 
operation  is  performed: 

MACitext) t  =  HMAC(K,  text),  =  H((Kq  ©  opad  )li  H((Kq  ©  ipad )  I!  text))l 

Table  1  illustrates  the  step  by  step  process  in  the  HMAC  algorithm,  which  is  depicted  in 
Figure  1. 


Table  1:  The  HMAC  Algorithm 


STEPS 

STEP-BY-STEP  DESCRIPTION 

Step  1 

If  the  length  of  K  =  B:  set  Kq  =  K.  Go  to  step  4. 

Step  2 

If  the  length  of  K  >  B:  hash  K  to  obtain  an  L  byte  string,  then  append  (B-L) 
zeros  to  create  a  B-byte  string  Kq  (i.e.,  Kq  =  H(if)  II  00. ..00).  Go  to  step  4. 

Step  3 

If  the  length  of  K  <  B:  append  zeros  to  the  end  of  K  to  create  a  B-byte  string  Kq 
(e.g.,  if  K  is  20  bytes  in  length  and  B  =  64,  then  K  will  be  appended  with  44 
zero  bytes  0x00). 

Step  4 

Exclusive-Or  Kq  with  ipad  to  produce  a  B-byte  string:  Kq  ©  ipad. 

Step  5 

Append  the  stream  of  data  'text'  to  the  string  resulting  from  step  4: 

(Kq  ©  ipad )  II  text. 

Step  6 

Apply  H  to  the  stream  generated  in  step  5:  W((Kq  ©  ipad )  II  text). 

Step  7 

Exclusive-Or  K0  with  opad:  Kq  ©  opad. 

Step  8 

Append  the  result  from  step  6  to  step  7 : 

(Kq  ©  opad )  II  HKAo  ©  ipad)  II  text). 

Step  9 

Apply  H  to  the  result  from  step  8: 

H((Kq  ©  opad  )ll  H((Kq  ©  ipad)  II  text)). 

Step  10 

Select  the  leftmost  t  bytes  of  the  result  of  step  9  as  the  MAC. 

4 


Steps  1-3: 


Step  4: 


Step  5: 


Step  6: 


Step  7: 


Step  8: 


Step  9: 


Step  10: 


Figure  1:  Illustration  of  the  HMAC  Construction 


IMPLEMENTATION  NOTE 


The  HMAC  algorithm  is  specified  for  an  arbitrary  Approved  cryptographic  hash  function, 
H.  With  minor  modifications,  an  HMAC  implementation  can  easily  replace  one  hash 
function,  H ,  with  another  hash  function,  H’. 

Conceptually,  the  intermediate  results  of  the  compression  function  on  the  5-byte  blocks 
(Kq  ©  ipad)  and  (K0  ©  opad)  can  be  precomputed  once,  at  the  time  of  generation  of  the 
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key  K,  or  before  its  first  use.  These  intermediate  results  can  be  stored  and  then  used  to 
initialize  H  each  time  that  a  message  needs  to  be  authenticated  using  the  same  key.  For 
each  authenticated  message  using  the  key  K,  this  method  saves  the  application  of  the  hash 
function  of  H  on  two  5-byte  blocks  (i.e.,  on  ( K  ©  ipad)  and  ( K  ©  opad )).  This  saving 
may  be  significant  when  authenticating  short  streams  of  data.  These  stored 
intermediate  values  shall  be  treated  and  protected  in  the  same  manner  as  secret 
keys. 

Choosing  to  implement  HMAC  in  this  manner  has  no  effect  on  interoperability. 

Object  identifiers  (OIDs)  for  HMAC  are  posted  at  http://csrc.nist.gov/csor.  along  with 
procedures  for  adding  new  OIDs. 
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APPENDIX  A:  HMAC  EXAMPLES 


These  examples  are  provided  in  order  to  promote  correct  implementations  of  HMAC. 
The  SHA-1  hash  function  used  in  these  examples  is  specified  in  [4]. 

A.l  SHA-1  with  64-Byte  Key 

Text:  "Sample#!" 


Key: 

00010203 

04050607 

0  8  0  90a0b 

OcOdOeOf 

10111213 

14151617 

1 8 1 91alb 

lcldlel f 

20212223 

24252627 

2  82  92a2b 

2c2d2e2f 

30313233 

34353637 

38393a3b 

3c3d3e3f 

K0: 

00010203 

04050607 

0  8  0  90a0b 

OcOdOeOf 

10111213 

14151617 

1 8 1 91alb 

lcldlel f 

20212223 

24252627 

2  82  92a2b 

2c2d2e2f 

30313233 

34353637 

38393a3b 

3c3d3e3f 

Ko© 

ipad: 

36373435 

32333031 

3e3f 3c3d 

3a3b3839 

26272425 

22232021 

2e2f 2c2d 

2a2b282  9 

16171415 

12131011 

lelf lcld 

lalbl819 

06070405 

02030001 

OeOf OcOd 

0a0b0809 

(Key  ©  ipad)lltext: 


36373435 

32333031 

3e3f 3c3d 

3a3b3839 

26272425 

22232021 

2e2f 2c2d 

2a2b282  9 

16171415 

12131011 

lei  field 

lalbl819 

06070405 

02030001 

OeOf OcOd 

0a0b0809 

53  61 6d7  0 

6c652023 

31 

Hash((Key  ©  ipad)lltext): 

bcc2c68c  abbbflc3 

f 5b05d8e 

7e73a4d2 

7b7elb2  0 

Ko  ©  opad: 

5c5d5e5f 

58595a5b 

54555657 

50515253 

4c4d4e4f 

48494a4b 

44454647 

40414243 

7c7d7e7f 

78797a7b 

74757677 

70717273 

6c6d6e6f 

68  6  9  6a  6b 

64656667 

60616263 

(K0  ©  opad)  II  Hash((Key  ©  ipad)lltext): 

5c5d5e5f  58595a5b  54555657 

50515253 

4c4d4e4f 

48494a4b 

44454647 

40414243 
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7c7d7e7f 
6c6d6e6f 
bcc2c68c 
7b7elb2  0 


78797a7b 
68  6  9  6a  6b 
abbbf lc3 


74757677 
64656667 
f 5b05d8e 


70717273 

60616263 

7e73a4d2 


HMAC(Key,  Text)  =  Hash((K0  ©  opad)  II  Hash((Key  ©  ipad)lltext)) 


4f4ca3d5  d68ba7cc 
a0403c0a 

0al208c9 

c61e9c5d 

20-byte  HMAC(Key,  Text): 

4f4ca3d5  d68ba7cc 

a0403c0a 

0al208c9 

c61e9c5d 

A.2  SHA-1  with  20-Byte  Key 


Text: 

"Sample  #2" 

Key: 

30313233 

34353637 

38393a3b 

3c3d3e3f 

40414243 

K0: 

30313233 

34353637 

38393a3b 

3c3d3e3f 

40414243 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

Kq  ©  ipad: 

06070405 

02030001 

OeOf OcOd 

OaObO  8  0  9 

76777475 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

(Key  ©  ipad)lltext: 

06070405 

02030001 

OeOf OcOd 

OaObO  8  0  9 

76777475 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

36363636 

53616d70 

6c652023 

32800000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000248 

Hash((Key  ©  ipad)lltext): 

747  66e5f  6913e8cb  6f7fl08a  11298bl5 

0 1 0c353a 
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Kq  ©  opad: 

6c6d6e6f  68696a6b  64656667 

lcldlelf  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c 


60616263 

5c5c5c5c 

5c5c5c5c 

5c5c5c5c 


(Ko  ©  opad)  II  Hash((Key  ©  ipad)lltext): 

6c6d6e6f  68696a6b  64656667  60616263 

lcldlelf  5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c  5c5c5c5c 
747  66e5f  6913e8cb  6f7fl08a  11298bl5 

0 1 0c353a 


HMAC(Key,  Text)  =  Hash((K0  ©  opad)  II  Hash((Key  ©  ipad)lltext)) 

0  922d34  0  5faa3dl9  4f82a458  30737d5c 

c6c75d24 

20-byte  HMAC(Key,  Text): 

0  922d34  0  5faa3dl9  4f82a458  30737d5c 

c6c75d24 


A.3  SHA-1  with  100-Byte  Key 


Text: 

"Sample  #3” 

Key:  50515253 

54555657 

58595a5b 

5c5d5e5f 

60616263 

64656667 

68  6  9  6a  6b 

6c6d6e6f 

70717273 

74757677 

78797a7b 

7c7d7e7f 

80818283 

84858687 

8  8  8  98a8b 

8c8d8e8f 

90919293 

94959697 

98  999a9b 

9c9d9e9f 

a0ala2a3 

a4a5a6a7 

a8a9aaab 

acadaeaf 

b0blb2b3 

Hash(Key): 

a4aabel 6 

54e7  8da4 

40d2a403 

015636bf 

4bb2f 32  9 

Kq:  a4aabel6 

54e7  8da4 

40d2a403 

015636bf 

4bb2f 32  9 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

00000000 

Kq  ©  ipad: 
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92  9c8  82  0  62dlbb92  76e49235  37600089 
7d84c51f  36363636  36363636  36363636 
36363636  36363636  36363636  36363636 

36363636  36363636  36363636  36363636 

(Key  ©  ipad)lltext: 

92  9c8  82  0  62dlbb92  76e49235  37600089 

7d84c51f  36363636  36363636  36363636 

36363636  36363636  36363636  36363636 

36363636  36363636  36363636  36363636 

53  61 6d7  0  6c652023  33 

Hash((Key  ©  ipad)lltext): 

d98315c4  2152bea0  d057de97  84427676 

2ala557  6 

Kq  ©  opad: 

f 8f 6e24a  08bbdlf8  Ic8ef85f  5d0a6ae3 
17eeaf75  5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c  5c5c5c5c 

(Ko  ©  opad)  II  Hash((Key  ©  ipad)lltext): 

f 8f 6e24a  08bbdlf8  Ic8ef85f  5d0a6ae3 
17eeaf75  5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c  5c5c5c5c 
5c5c5c5c  5c5c5c5c  5c5c5c5c  5c5c5c5c 
d98315c4  2152bea0  d057de97  84427676 

2ala557  6 

HMAC(Key,  Text)  =  Hash((K0  ©  opad)  II  Hash((Key  ©  ipad)lltext)): 

bcf41eab  8bb2d802  f3d05caf  7cb092ec 
f 8dla3aa 

20-byte  HMAC(Key,  Text): 

bcf41eab  8bb2d802  f3d05caf  7cb092ec 
f 8dla3aa 


A.4  SHA-1  with  49-Byte  Key,  Truncated  to  12-Byte  HMAC 

Text:  "Sample  #4" 

Key:  70717273  74757677  78797a7b  7c7d7e7f 

80818283  84858687  88898a8b  8c8d8e8f 

90919293  94959697  98999a9b  9c9d9e9f 


10 


aO 


K0:  70717273 

74757677 

78797a7b 

7c7d7e7f 

80818283 

84858687 

8  8  8  98a8b 

8c8d8e8f 

90919293 

94959697 

98  999a9b 

9c9d9e9f 

aOOOOOOO 

00000000 

00000000 

00000000 

Kq  ©  ipad: 

46474445 

42434041 

4e4f 4c4d 

4a4b484  9 

b6b7b4b5 

b2b3b0bl 

bebfbcbd 

babbb8b9 

a6a7a4a5 

a2a3a0al 

aeaf acad 

aaaba8a9 

96363636 

36363636 

36363636 

36363636 

(Key  ©  ipad)lltext: 

46474445 

42434041 

4e4f 4c4d 

4a4b484  9 

b6b7b4b5 

b2b3b0bl 

bebfbcbd 

babbb8b9 

a6a7a4a5 

a2a3a0al 

aeaf acad 

aaaba8a9 

96363636 

36363636 

36363636 

36363636 

53  61 6d7  0 

6c652023 

34 

Hash((Key  ©  ipad)lltext): 

bfle889d  876c34b7 

bef 3496e 

d998c8dl 

16673a2e 

Ko  ©  opad: 

2c2d2e2f 

2  82  92a2b 

24252627 

20212223 

dcdddedf 

d8d9dadb 

d4d5d6d7 

d0dld2d3 

cccdcecf 

c8c9cacb 

c4c5c6c7 

c0clc2c3 

f c5c5c5c 

5c5c5c5c 

5c5c5c5c 

5c5c5c5c 

(K0  ©  opad)  II  Hash((Key  ©  ipad)lltext): 

2c2d2e2f  28292a2b  24252627 

20212223 

dcdddedf 

d8d9dadb 

d4d5d6d7 

d0dld2d3 

cccdcecf 

c8c9cacb 

c4c5c6c7 

c0clc2c3 

f c5c5c5c 

5c5c5c5c 

5c5c5c5c 

5c5c5c5c 

bf le8  8  9d 

16673a2e 

87  6c34b7 

bef 3496e 

d998c8dl 

HMAC(Key,  Text)  = 

9ea8  8  6ef 

Hash((K0  © 

e2  68dbec 

opad)  II  Hash((Key  ©  ipad)lltext)) 

ce420c75  24df32e0 

751a2a26 

12-byte  HMAC(Key, 
9ea886ef 

Text): 

e268dbec 

ce420c75 
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APPENDIX  B:  A  LIMITATION  OF  MAC  ALGORITHMS 


The  successful  verification  of  a  MAC  does  not  completely  guarantee  that  the 
accompanying  message  is  authentic:  there  is  a  chance  that  a  source  with  no  knowledge 
of  the  key  can  present  a  purported  MAC  on  the  plaintext  message  that  will  pass  the 
verification  procedure.  For  example,  an  arbitrary  purported  MAC  of  t  bits  on  an  arbitrary 
plaintext  message  may  be  successfully  verified  with  an  expected  probability  of  (1/2/. 
This  limitation  is  inherent  in  any  MAC  algorithm. 

The  limitation  is  magnified  if  an  application  permits  a  given  non-nauthentic  message  to 
be  repeatedly  presented  for  verification  with  different  purported  MACs.  Each  individual 
trial  succeeds  only  with  a  small  probability,  (1/2/;  however,  for  repeated  trials,  the 
probability  increases  that,  eventually,  one  of  the  MACs  will  be  successfully  verified. 
Similarly,  if  an  application  permits  a  given  purported  MAC  to  be  presented  with  different 
non-authentic  messages,  then  the  probability  increases  that,  eventually,  the  MAC  will  be 
successfully  verified  for  one  of  the  messages. 

Therefore,  in  general,  if  the  MAC  is  truncated,  then  its  length,  t ,  should  be  chosen  as 
large  as  is  practical,  with  at  least  half  as  many  bits  as  the  output  block  size,  L.  The 
minimum  value  for  t  is  relaxed  to  32  bits  for  applications  in  which  the  two  types  of 
repeated  trials  that  are  described  in  the  previous  paragraph  are  sufficiently  restricted.  For 
example,  the  application,  or  the  protocol  that  controls  the  application,  may  monitor  all  of 
the  plaintext  messages  and  MACs  that  are  presented  for  verification,  and  permanently 
reject  any  plaintext  message  or  any  MAC  that  is  included  in  too  many  unsuccessful  trials. 
Another  example  occurs  when  the  bandwidth  of  the  communications  channel  is  low 
enough  to  preclude  too  many  trials,  of  either  type.  In  both  cases,  the  maximum  number  of 
allowed  unsuccessful  trails  must  be  pre-determined  based  on  the  risks  associated  with  the 
sensitivity  of  the  data,  the  length  of  t  and  the  MAC  algorithm  used. 
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